Description

Changes proposed in this pull request:

• allow migration when k8s-default-tools are disabled/not bound
• use install internal command to perform Botkube installation
• use kubex.LoadRestConfigWithMetaInformation() and register --kubeconfig flag, to get OOTB experience with finding current k8s context
• print cluster context name to tell the user against which cluster migration is executed
• generate unique configurationName
• Botkube CLI help specifies that botkube install is used for both installation and upgrading an existing Botkube instance.

Testing

Create Botkube instance in your local env
Login and migrate

helm upgrade botkube --install --version v1.2.0 --namespace botkube --create-namespace --wait   --set communications.default-group.socketSlack.enabled=true   --set communications.default-group.socketSlack.channels.default.name=${SLACK_CHANNEL_NAME}   --set communications.default-group.socketSlack.appToken=${SLACK_API_APP_TOKEN}   --set communications.default-group.socketSlack.botToken=${SLACK_API_BOT_TOKEN}   --set executors.k8s-default-tools.botkube/kubectl.enabled=true   --set settings.clusterName=${CLUSTER_NAME}   --set settings.log.level=debug   --set analytics.disable=true   botkube/botkube

go run cmd/cli/main.go login --cloud-dashboard-url=http://localhost:3000
go run cmd/cli/main.go migrate -w --cloud-api-url=http://localhost:8080/graphql --cloud-dashboard-url=http://localhost:3000

For testing that Actions can be migrated even when a bound plugin is not defined - rename a plugin in one of the pre-defined actions and migrate. The Action should be omitted and not included in the migration.

Related issue(s)

#1172